Add Book to My BookshelfPurchase This Book Online

Chapter 6 - Supporting Popular WAN Technologies

Cisco TCP/IP Routing Professional Reference
Chris Lewis
  Copyright © 1999 The McGraw-Hill Companies, Inc.

Frame Relay
Frame relay is a layer 2 WAN protocol and, as such, does not understand the concept of network numbers. In a LAN, layer 2 addressing is normally defined by MAC addresses. In frame relay, addressing is defined by Data Link Connection Identifiers (DLCI, pronounced "del-see" by those familiar with frame relay implementations). DLCI numbers are not used as destination addresses such as LAN-based MAC addresses. A DLCI number only has significance locally, and not across the frame relay network.
Frame relay is a statistical multiplexed service. That means it allows several logical connections (often referred to as channels) to coexist over the same physical connection and allocates bandwidth dynamically among all users of that link. This is in contrast to a Time Division Multiplexed (TDM) service, which allocates a fixed amount of bandwidth to multiple channels on the same line. When frame relay was first introduced, many network engineers thought of it as a cut-down version of X.25. This was because frame relay is similar to X.25 in many ways, except it does not provide the same level of error correction. X.25 was designed as a packet switching network technology at a time when the wide area network links available were mainly analog lines that were prone to periods of poor transmission quality, and that introduced errors into packets transmitted across a network.
When frame relay was introduced, more and more digital circuits were available that provided better-quality transmission and, on average, higher reliability. Also, higher-level protocols such as TCP that performed error correction and flow control were becoming increasingly popular. The designers of frame relay decided, therefore, to cut out all the link-level acknowledgments and other overhead associated with X.25 connections that were there to deal with unreliable links.
Frame relay performs as much error checking as does Ethernet in that a Frame Check Sequence (FCS) derived from a Cyclic Redundancy Check (CRC) calculation is appended to each frame sent, which is checked by the receiving station. This FCS allows a receiving station to disregard a frame that has been altered in transit; however, neither frame relay nor Ethernet will re-request the damaged frame. Frame relay, therefore, offers better utilization of available bandwidth and is faster at transferring data than X.25, because it does not have to generate, receive, or process acknowledgments.
Frame relay does rely on the applications communicating over a frame relay link to handle error recovery. If an application uses a connection-oriented protocol such as TCP for its Transport layer protocol, TCP will handle error recovery and flow control issues. If an application uses a connectionless protocol such as UDP for its Transport layer protocol, specific programming within the application must be coded to handle error recovery and flow control.
X.25 as a specification merely dealt with how a DTE device will communicate with a DCE device and made no mention of how packets would get routed through a network. That's the same with frame relay. Frame relay networks may use a variety of mechanisms to route traffic from source to destination, and each one is proprietary to a vendor or group of vendors. What this means to us is that, typically, a Cisco router will be configured to connect to a public frame relay service without regard as to how the packets that are sent over that network are routed.
Frame relay and X.25 both operate using the concepts of a permanent virtual circuit (PVC) and a switched virtual circuit (SVC). An SVC uses a Call Setup procedure to establish a connection from source to destination in the same way a telephone does. A PVC is permanently connected between source and destination and operates in much the same way as a leased line. Although frame relay originally was proposed as a standard for packet transmission over ISDN using SVCs, it has gained far wider acceptance as a WAN technology using PVCs on a shared public network.
Let me say first of all that I see little point in implementing frame relay on a private network. Frame relay makes the most sense when the same network is going to be used by many organizations and sharing of the bandwidth between locations is called for. I therefore will restrict the rest of this discussion with the assumption that we are talking about connecting Cisco routers at one or more locations to a public shared frame relay service.
Before we look into the details of frame relay, let's look at when frame relay is appropriate and identify some of its pitfalls. Frame relay is ideally suited to networks that fit the following criteria:
  Many geographically dispersed locations need a permanent connection to a central site, but cannot cost-justify the provision of a leased circuit from each of the remote sites to the central location.
  The traffic to be transported tends to come in bursts or spurts, rather than in a constant stream.
  Applications accessed over the frame relay connection use a connection-oriented protocol to handle error recovery and flow control.
  Unpredictable application response time is not a big issue.
  Remote sites change location, or new sites are added on a regular basis.
If a network's goals match closely with the above, frame relay is a technology to consider. What makes frame relay attractive from the telephone company's point of view is that bandwidth can be allocated among many customers. When viewed statistically for a large population on the frame relay network, this makes sense. The probability that thousands of customers all want to use the network to the full extent at the same time is statistically quite small. Therefore, if everyone takes their proper turn at the bandwidth, the telephone company can sell more bandwidth than is available throughout the network. This enables the telephone company to offer a cheaper service via a shared frame relay network, but one that does not come with the same guarantees of throughput. This cheaper service often is billed at the same rate irrespective of location, and so is particularly attractive for connecting remote sites that may be thousands of miles away.
To counter user concerns over throughput guarantees, there is a frame relay feature called the Committed Information Rate (CIR). Prior to implementation of CIR, a user would get, for example, a 64 kbps line into a commercial frame relay service, but the throughput would vary, depending on other customer utilization of the frame relay network. Sometimes the throughput was unacceptable. The CIR guarantees a customer that the throughput on any given link would not drop below the CIR rate. In addition to the CIR, an agreement with a frame relay service provider generally allows a customer to have bursts of traffic up to another specified level, typically the speed of the connection into the frame relay service.
Shared frame relay services are certainly a cost-effective way to provide remote branches with occasional access to central e-mail, gateway, and application servers for internal users who can accept occasional slow response times. Frame relay is not appropriate for delivering mission-critical, bandwidth-intensive applications to external customers. If a frame relay service is to be used for an application that needs guaranteed throughput, the CIR must be set to the guaranteed bandwidth needed. This can be as expensive as getting dedicated bandwidth from the same telephone company.
There is a final concern I want to share with you before we move on to look at this technology in more detail. In Fig. 6-1, we see a typical frame relay implementation for a company with five remote branches.
Figure 6-1: Typical frame relay network configuration
Router 1 connects the central site with the servers to a commercial frame relay service. Routers 2 through 6 connect remote branches to the same frame relay service. Frame relay is not a broadcast medium, so any routing updates, or SAP updates for IPX traffic, need to be sent point-to-point to each location. This can tax the link from router 1 into the frame relay network as the number of branches grows. It is not uncommon to find 50 percent or more of a central site router's bandwidth into the frame relay service consumed with routing information packets. This situation can be avoided, as we shall see later, but requires careful design and a good knowledge of how the interconnected systems work. Frame relay should never be considered a plug-and-play technology.
Frame Relay Terms
The first frame relay term you need to understand, the DLCI, already has been introduced. A DLCI is supplied for each end of a PVC by the frame relay provider. A DLCI number is used to identify each PVC defined at a location. At the central location shown in Fig. 6-1, there are DLCI numbers 1, 4, 6, 8, and 10. It is best to think of each DLCI as identifying a pipe that leads to a specific protocol address. For example, DLCI 1 leads to the IP address of Serial 0 on router 2, DLCI 4 leads to the IP address of Serial 0 on router 3, and so forth.
If you are implementing a TCP/IP solution over frame relay, remember that frame relay is a layer 2 protocol. All routers connected together via the frame relay cloud are peers. The key difference between a frame relay cloud and a LAN is that the frame relay cloud does not support broadcasts to all destinations as would a LAN. Referring to Fig. 6-1, this implies that all the Serial 0 ports on the routers shown would be in the same IP subnet and all the Ethernet 0 ports shown would have their own subnets. We will look at this in more detail in the section on "Configuring Frame Relay Features."
As with most networking technologies, there are several configuration options, and here we will look at the most common.
Basic frame relay is depicted in Fig. 6-2 and merely connects two locations together over a PVC. This is not very different from connecting these sites together via a leased line. The only difference is the fact that the bandwidth between the two sites is shared with other users of the frame relay network.
Figure 6-2: Simple frame relay connectivity
In this figure, router 1 is connected to router 2 via a PVC, which is defined within the frame relay cloud as existing from DLCI 1 to DLCI 2. In basic frame relay, other locations within the frame relay cloud could use these DLCI numbers because a DLCI has only local significance. This type of frame relay use is limited and has been superseded by use of what is known as the LMI extensions.
LMI stands for Local Management Interface and provides additional frame relay features that include:
  Use of Inverse ARP to automatically determine the protocol address of the device on the remote end of a DLCI.
  Simple flow control to provide XON/XOFF-type flow control for the interface as a whole. This is intended for applications communicating over frame relay that cannot use the congestion flags sent by frame relay networks.
  Multicasting to allow the sender to send one copy of a frame that will be delivered to multiple destinations. This is useful for routing update and address resolution protocol traffic.
  Virtual Circuit Status messaging to allow LMI-enabled network connections to maintain information about the status of PVCs across the network, notifying other nodes if one node becomes unreachable.
Cisco joined with Northern Telecom, Stratacom, and DEC to define an LMI standard to deliver these benefits in anticipation of an open standard for LMI. The other commonly implemented LMI type is now ANSI, which was defined by that standards body some time after the four vendors above released theirs.
In addition to the LMI type, you can set the frame relay encapsulation to either Cisco or IETF if you are connecting to another vendor's equipment across a frame relay network. Cisco did not create these additional options to make an open standard proprietary or to make life difficult. Rather, Cisco created these standards in order to deliver benefits to users prior to standards bodies making a workable definition available to those wanting to deploy frame relay networks.
Configuring Frame Relay Features
As stated previously, frame relay is a technology that connects two end points across a network. These end points are identified within the network by DLCI numbers; the DLCI-to-DLCI connection is known as a PVC. We will examine configuration of a central Cisco router serial interface, first in a frame relay point-to-point connection, then in a multipoint connection, and finally with sub-interfaces. We also will explain how inverse ARP simplifies configuration and why the Split Horizon algorithm is not enabled on frame relay ports (unless sub-interfaces are used).
Basic Configuration.     The simplest example of frame relay is that shown in Fig. 6-2. In that case, the frame relay provider assigns a DLCI address of 1 to the location of router 1, and 2 to the location with router 2. Let's look at how we build the configuration for the serial port of router 1.
In interface configuration mode for the Serial 0 port of router 1, type the following:
Router1(config-int)#ip address 132.3.8.7 255.255.255.0
Router1(config-int)#encapsulation frame relay
This defines frame relay encapsulation for the Serial 0 port. The only optional argument that can be supplied on this command is ietf, which would configure the interface to use the IETF rather than the Cisco encapsulation. Your frame relay provider will inform you if this argument is necessary.
The next configuration entry will be to define the LMI type. This command can have one of three values. The default is Cisco, while optional arguments can specify ANSI or q933a, the latter being the ITU standard. Again, your frame relay provider should let you know which to use.
Router1(config-int)#frame-relay lmi-type ansi
Next we have to tell the router which destination DLCI should be used to reach a given IP address. This discussion assumes that manual configuration of frame relay maps is necessary; in a subsequent section we will examine how inverse ARP makes this unnecessary. For router 1, the 132.3.8.0 subnet is reachable through the Serial 0 interface, so all packets for that subnet are sent out Serial 0. The frame relay supplier will have set up the PVC to send anything that originates at one end of the PVC out the other end.
The potential exists for many PVCs to be associated with one physical interface, so we must tell the serial port which DLCI number to use to get to which protocol address destination. Therefore, we have to tell it that to reach IP address 132.3.8.9, it will use DLCI 1. With this DLCI information, the frame relay network can deliver the packet to its desired destination. This configuration is achieved with the following command:
Router1(config-int)#frame-relay map ip 132.3.8.9 1 broadcast
The argument broadcast enables router 1 to send broadcast routing updates to router 2 through this PVC. If the Serial 0 port on router 2 were to be configured in the same way, the two routers could communicate via frame relay. With only one PVC, this level of configuration may seem like overkill—and it is—but the next example will show why it is necessary. Later in this chapter, when we use our three lab routers to configure a test frame relay network, we will see that a properly configured network and interface will remove the need to enter multiple frame-relay map commands.
This is all well and good, but it is not taking advantage of one of the main benefits of frame relay, which is the ability to multiplex many links onto one. This feature tends to be useful for a central router that must connect to many remote sites, a situation shown in Fig. 6-1. To enable router 1 in Fig. 6-1 to reach routers 2 through 6, the configuration we have so far can be extended with additional map statements. The first step, however, will be to buy the additional PVCs from the frame relay carrier and obtain the local DLCI numbers that identify PVCs to all the remote locations. Assume we are delivered the following DLCI assignments and IP address allocations:
Router
Serial 0 IP Address
DLCI at router 1
Remote DLCI
1
132.3.8.7
2
132.3.8.9
1
3
3
132.3.8.8
4
5
4
132.3.8.10
6
7
5
132.3.8.11
8
9
6
132.3.8.12
10
11
To reach all remote routers, router 1 would need the configuration shown in Fig. 6-3. This shows that router 1 has 5 DLCIs configured, and tells it which DLCI to use to get the packets delivered to the appropriate IP address. At first it may seem that, by addressing packets to a DLCI number that is defined at the router 1 location, the packets are not really being sent anywhere. The best way to think of this, though, is to think of each DLCI as a pipe, and as long as router 1 puts the packet in the correct pipe, the frame relay network will deliver the packet to the correct destination.
Inverse ARP.     As you can see, configuring all these frame relay map statements can become a bore, especially if you have upwards of 20 locations. Fortunately there is a mechanism that will save us from all this manual effort, and that is Inverse ARP. Inverse ARP works in conjunction with the LMI to deliver enough information to routers attached to a frame relay network, so that no frame relay map statements need to be manually configured.
INTERFACE SERIAL 0
IP ADDRESS 132.3.8.7 255.255.255.0
ENCAPSULATION FRAME RELAY
FRAME-RELAY LMI-TYPE ANSI
FRAME-RELAY MAP IP 132.3.8.9 1 BROADCAST
FRAME-RELAY MAP IP 132.3.8.8 4 BROADCAST
FRAME-RELAY MAP IP 132.3.8.10 6 BROADCAST
FRAME-RELAY MAP IP 132.3.8.11 8 BROADCAST
FRAME-RELAY MAP IP 132.3.8.12 10 BROADCAST
Figure 6-3: Configuration for router 1 in Figure 6-1
Upon startup, the LMI will announce to an attached router all the DLCI numbers that are configured on the physical link connecting the router to the network. The router will then send Inverse ARP requests out each DLCI to find out the protocol address configured on the other end of each DLCI's PVC. In this way, a router will generate its own list of what IP addresses are reachable through which DLCI number.
Fully Meshed Frame Relay Networks.     For IP implemented over frame relay networks, the Split Horizon rule is disabled. This allows a central router to readvertise routes learned from one remote location on a serial interface to other remote locations connected to the same serial interface. In Fig. 6-1, this means that all routers will end up with entries in their routing tables for net 1 through net 6.
Some other protocols, such as those used in Apple networking, will not allow Split Horizon to be turned off, so routes cannot be readvertised out of the interface from which they were learned. To provide full routing capability across a frame relay network with these protocols requires a separate link from each location to every other location. This type of connectivity is referred to as a fully meshed network (Fig. 6-4).
Figure 6-4: Fully meshed frame relay network
A fully meshed network gives each router a specific DLCI number with which to reach every other router. This scheme does allow complete communication between all locations, but requires a large number of PVCs to be bought from the frame relay provider. As the number of nodes on the network increases, the number of PVCs needed grows exponentially, which can make this technology uneconomic to deploy. Now that Cisco has made sub-interfaces available, however, we have a method to get around this for these Apple protocols.
Frame Relay Sub-Interfaces.     The simplest way to deploy sub-interfaces for full remote-branch-to-remote-branch connectivity is to implement sub-interfaces in a point-to-point configuration. Sub-interfaces can be deployed as point-to-point, or multipoint (the default).
A sub-interface allows you to effectively split one physical port into multiple logical ports. The advantage this gives is that if you configure the sub-interfaces as point-to-point links, each sub-interface is treated as if it were a separate connection by the layer 3 protocol and each sub-interface will appear as a separate entry in the routing table, with a different subnetwork ID associated with it. A sub-interface configured in multipoint mode behaves the same as the interfaces we have configured so far. Let's look at how a sub-interface configured in point-to-point mode allows us to configure a fully meshed network for protocols that cannot disable Split Horizon, without buying additional PVCs and DLCIs from a frame relay provider.
What we want to achieve with a sub-interface is to assign a complete subnet to each PVC, so that a router with multiple PVCs terminating in its serial port (that is, the serial port has multiple DLCI numbers associated with it in the frame relay network) will assign a separate entry in its routing table for each PVC link (Fig. 6-5).
Figure 6-5: Sub-interfaces on a frame relay connection
If router 1 is appropriately configured with sub-interfaces, it will have a separate entry in its routing table for the PVC that goes from itself to router 2, and from itself to router 3. Let's take a look at the configuration of these three routers as shown in Fig. 6-6.
This configuration assumes that the default encapsulation and LMI type is in effect, and that Inverse ARP (enabled by default on a frame relay port) is not disabled. For router 1 we have sub-interface 0.1 and 0.2 on separate subnets.
CONFIGURATION FOR ROUTER 1
INTERFACE SERIAL 0
ENCAPSULATION FRAME RELAY
INTERFACE S0.1 POINT-TO-POINT
FRAME-RELAY INTERFACE-DLCI 1 BROADCAST
IP ADDRESS 164.8.5.1 255.255.255.0
!
INTERFACE S 0.2 POINT-TO-POINT
FRAME-RELAY INTERFACE DLCI 2 BROADCAST
IP ADDRESS 164.8.6.1 255.255.255.0
CONFIGURATION FOR ROUTER 2
INTERFACE SERIAL 0
IP ADDRESS 164.8.5.2 255.255.255.0
ENCAPSULATION FRAME RELAY
!
CONFIGURATION FOR ROUTER 3
INTERFACE SERIAL 0
IP ADDRESS 164.8.6.2 255.255.255.0
ENCAPSULATION FRAME RELAY
!
Figure 6-6: Router configuration for frame relay sub-interfaces
Sub-interface 0.1 is configured for subnet 164.8.5.0 and is associated with DLCI 1. The Serial 0 port on router 2 is configured for an IP address on the same subnet and by the LMI/Inverse ARP process described earlier will map DLCI 14 to IP address 164.8.5.1.
Similarly, the sub-interface 0.2 has an IP address configured on the same subnet as the Serial 0 port on router 3. Router 3 also will use the LMI/inverse ARP process to map DLCI 13 to IP address 164.8.6.1.
With this configuration, router 1 will have separate entries in its routing table for the subnets used by router 2 and router 3. Router 1 will broadcast routing updates to router 2 and router 3, so that both routers get their routing tables updated with entries for the 164.8.5.0 and 164.8.6.0. subnetwork. This allows router 2 and router 3 to communicate with each other via router 1.
This type of configuration makes the serial interface on router 1 appear as multiple interfaces to the layer 3 protocols, but on a Data Link and Physical layer it is considered one interface, with multiple PVCs multiplexed on it by the frame relay network.
Configuring a Test Frame Relay Network
We will now reconfigure our three lab routers to have one perform the function of a frame relay switch. Two other routers will be configured as remote branches connecting into the frame relay switch. The configuration we will use is shown in Fig. 6-7.
Figure 6-7: Configuration for a test frame relay network
In this configuration, router 1 takes the place of a frame relay cloud. To build this lab environment, the first thing we must do is ensure that the DTE/DCE cables connecting router 1 to router 2 and router 3 are connected with the correct polarity. The goal here is to get both serial ports on router 1 to act as DCE rather than DTE, and the only way to do that in a lab environment—using cables instead of CSU/DSU devices to connect routers—is to connect the correct end of a DTE/DCE cable into the serial port. Use the show controller serial 0 command after you have connected the DTE/DCE cable to the Serial 0 port. If the output from this command indicates a DTE configuration, use the other end of the cable to connect to router 1. The same goes for the Serial 1 port.
The configuration shown in Fig. 6-7 uses the default Cisco frame relay encapsulation and LMI, as well as leaving Inverse ARP functioning. Router 1 is configured as a pure frame relay switch. The following explains all the frame relay entries in this configuration.
  Global command frame-relay switching enables the frame relay switching process for this router and must be enabled before any interface configuration commands are entered.
  Command encapsulation frame-relay sets frame relay encapsulation for this interface.
  Command frame-relay intf-type dce sets the interface as a frame relay DCE device. The default is DTE; therefore routers 2 and 3, which need to be DTE, do not have a corresponding command.
  Command frame-relay route 17 interface serial1 18 configures the static routing of the switch based on DLCI number. The command syntax configures the router so that any packets inbound on DLCI 17 will be routed out interface Serial 1, on DLCI 18 (note that DLCIs can have a value in the range 16–1007). The values shown are for the Serial 0 port; for the Serial 1 port, packets are inbound on DLCI 18 and routed to Serial 0 on DLCI 17.
The configuration for routers 2 and 3 should be self-explanatory by this stage; however, it is worth noting that the frame relay maps are generated through the LMI and Inverse ARP mechanism and require no explicit configuration of either router. Note that IGRP was configured for both router 2 and router 3, and because broadcasts are enabled by default, routing information traversed the frame relay switch, updating the routing tables of router 2 and 3. Therefore, router 2 is able to ping the
Ethernet port of router 3 and vice versa. Figure 6-8 shows the output of some interesting frame relay show commands that can be used to view the state of the frame relay network.
SHOW FRAME-RELAY ROUTE COMMAND ON ROUTER 1
INPUT DLCIOUTPUT INTTOUTPUT DLCISTATUS
SERIAL 017SERIAL 118ACTIVE
SERIAL 118SERIAL 017ACTIVE
SHOW FRAME-RELAY PVC FOR ROUTER 1
PVC STATISTICS FOR INTERFACE SERIAL0 (FRAME  RELAY  DCE)
DLCI = 17, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = SERIAL0
OUTPUT 56IN BYTES 4378
DROPPED PKTS 0IN FECN PKTS 0
OUT FECN PKTS 0OUT BECN PKTS 0
OUT DE PKTS 0
LAST TIME PVC STATUS CHANGED 1:00:29
NUM PKTS SWITCHED 53
PVC STATISTICS FOR INTERFACE SERIAL1 (FRAME  RELAY  DCE)
DLCI = 18, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = SERIAL1
OUTPUT 53IN BYTES 4536
DROPPED PKTS 0IN FECN PKTS 0
OUT FECN PKTS 0OUT BECN PKTS 0
OUT DE PKTS 0
LAST TIME PVC STATUS CHANGED 1:03:01
NUM PKTS SWITCHED 56
SHOW FRAME-RELAY PVC FOR ROUTER 2
PVC STATISTICS FOR INTERFACE SERIAL0 (FRAME RELAY DTE)
DLCI = 17, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = SERIAL0
OUTPUT 57IN BYTES 4848
DROPPED PKTS 1IN FECN PKTS 0
OUT FECN PKTS 0OUT BECN PKTS 0
OUT DE PKTS 0
LAST TIME PVC STATUS CHANGED 1:05:24
SHOW FRAME LMI OUTPUT FOR ROUTER 2
INVALID PROT DISC 0
INVALID MSG TYPE 0
INVALID LOCK SHIFT 0
INVALID REPORT IE LEN 0
INVALID KEEP IE LEN 0
NUM STATUS MSGS RCVD 409
NUM STATUS TIMEOUTS 1
SHO FRAME MAP OUTPUT FOR ROUTER 2
SERIAL0 (UP): IP 163.4.8.2 DLCI 17(0X11, 0X410), DYNAMIC, BROADCAST, STATUS
DEFINED, ACTIVE
Figure 6-8: Useful show commands for the test network
The first output shown in Fig. 6-8 is for the show frame-relay route command, which is useful when trying to troubleshoot PVC problems. This command tells you which DLCIs are active and where they route from and to on the frame relay router interfaces. The other display for router 1 shows the output for the show frame-relay pvc command, which gives more detailed information on each DLCI operational in the switch. The number of dropped packets gives you an idea of how well the switch is performing its duties—clearly the fewer drops, the better.
If the number of drops is high, but you notice the FECN and BECN packets increasing more rapidly than usual, it could be an early sign that the network is running out of bandwidth. FECN and BECN packets indicate congestion on the network and tell switches to hold off sending traffic. As long as the packet buffers in switches can hold traffic peaks, packets do not have to be dropped. If too many packets for the available bandwidth or buffers are coming in, however, the switch will drop packets at some stage. The show frame-relay pvc command for router 2 has the same display as discussed above, but only for DLCI 17, the one associated with router 2 in this network.
The next two displays show, respectively, the LMI status and the frame relay maps for router 2. The frame relay map is as expected, i.e., router 2 knows that the DLCI presented to it by the switch (DLCI 17) will lead it to IP address 163.4.8.2, which is on router 3.

 


 
Books24x7.com, Inc © 2000 –  Feedback